Modem data processing environments include both distributed processing in which an application running on a first data processing system utilizes the services of a second application running on a second data processing system. One such environment, for example, are web services. For the purposes herein, the application seeking the services, or equivalently, functionality, of the second application may be referred to as the client, and the application providing the functionality (and any communication interface associated therewith) may be referred to as the server.
Alternatively, modem data processing systems are also typically multiprocess environments, in which multiple processes may simultaneously share the competing resources of the system. (A process may be viewed as an instance of an application.) As would be appreciated by those of ordinary skill in the art, the multitasking capability may be effected via the operating system; the system hardware itself may constitute a single central processing unit (CPU). In such a multitasking environment, one process may utilize the services of another, second, process to provide functionality implemented in the second process. Such systems provide a mechanism for interprocess communications whereby the services of the second process may be requested by the first process. These will be discussed further hereinbelow in conjunction with FIG. 1.
To provide for the distribution of tasks among the processes as heretofore discussed, several mechanisms have been provided in the data processing art. For example, the Unix operating system (and derivatives thereof) provide a Remote Procedure Call (RPC) services. Other examples include the Remote Method Invocation (RMI) which is provided in the Java programming environment. Generally, a particular set of functionality in an application requires, in addition to the interface defining the methods of the application, a remote server that listens for requests from a client and a client that communicates with the remote server. In a typical implementation, the functionality that is to be remotely accessible is the same as that functionality provided locally. As changes are made to the functionality, either by adding functionality or removing functionality or both, the corresponding server and client code must be updated accordingly to mirror the changes made to the functional interface that defines the functionality available to the local process. This can be both a time consuming and an error prone process.
Consequently, there is a need in the art for mechanisms for automatically generating the code necessary to implement interprocess communications in distributed data processing system. (For the purposes herein, distributed data processing environments may be understood to refer both to environments including multiple data processing systems connected via a network and to environments in which the data processing systems support concurrent processes.) Additionally, it is advantageous that the architecture of the mechanism defines structures that permit the communication mechanism be substantially hidden from the client software. In other words, the client's software should be substantially transparent to the interprocess communication. That is, from the perspective of the client software, the client appears to be communicating within the local process although it may actually be communicating with a remote server running in a separate process (whether on a different or the same machine).